home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001088_KLENSIN@infoods.mit.edu _Tue May 11 19:36:49 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Return-Path: <KLENSIN@infoods.mit.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA15691; Tue, 11 May 93 19:36:49 MET DST
  4. Received: from INFOODS.MIT.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA29008; Tue, 11 May 1993 19:57:40 +0200
  6. Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
  7.  <01GY0SGODSS000064V@INFOODS.UNU.EDU>; Tue, 11 May 1993 13:57:13 EDT
  8. Date: Tue, 11 May 1993 13:57:13 -0400 (EDT)
  9. From: John C Klensin <KLENSIN@infoods.mit.edu>
  10. Subject: Re: Mail addresses as URLs
  11. In-Reply-To: <9305111604.AA03736@www3.cern.ch>
  12. To: timbl@nxoc01.cern.ch
  13. Cc: www-talk@nxoc01.cern.ch, uri@bunyip.com
  14. Message-Id: <737143033.452103.KLENSIN@INFOODS.UNU.EDU>
  15. X-Envelope-To: timbl@NXOC01.CERN.CH, www-talk@NXOC01.CERN.CH
  16. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  17. Content-Transfer-Encoding: 7BIT
  18. Mail-System-Version: <MultiNet-MM(330)+TOPSLIB(156)+PMDF(4.2)@INFOODS.UNU.EDU>
  19.  
  20. >well defined concept of a mailbox which
  21. >may or may not contain documents and may or may not have
  22. >restricted access. Perhaps "mailbox:" would be better than "mailto:".
  23. >Moving a document into somone's mail box is just like moving a
  24. >file into a directory: it is an operation with pre- and  
  25. >postconditions.
  26.  
  27. Maybe.  I'm not sure how far the distinction is important, but you can't
  28. externally specify delivery to my actual mailbox, nor can you determine
  29. how many of those I have and how your message will be routed by filters
  30. I impose on incoming mail.  All you get with a "mailbox name" is an
  31. abstraction with which you can deliver something to my host's mail user
  32. agent; after that, what happens to it is a local responsibility/issue
  33. that is traditionally not subject to Internet protocols.
  34.  
  35. >"telephoneto" like "telnet" doesn't fit into that model, and
  36. >so is less usefully integrated.
  37.    Actually, if you are trying to deliver an audio entity, or have
  38. text-to-speech capability, they are pretty similar in theory (the
  39. practice is different because we tend to attach different tools to
  40. mailboxes, but you can't predict this from the protocols).  Whether a
  41. telephone number addresses an individual or a group can't be determined
  42. in the general case.  Whether the message is recorded or discarded after
  43. first reading/hearing is a local matter, as are a series of possible
  44. forwarding and diversion operations.
  45.  
  46. >Is there not a subsyntax for the usermailbox@domain bit, with the
  47. >comment personal Name removed?  
  48.  
  49.   First, just to clarify for those who aren't used to the syntax (or who
  50. have seen it for years and not paid attention)...
  51.      (this is a comment)   It is, from a protocol standpoint, noise that
  52. can be discarded without loss of important information.
  53.      The personal name ("phrase" in RFC822-speak) isn't a comment, it is
  54. part of the address.  Mail systems have some obligation to preserve it
  55. (a rule often broken) and not map it into a comment or vice versa
  56. (thereby destroying or inventing information--also often broken).  In
  57. environments at the periphery of the network, where mailboxes cost
  58. money, personal names are often used to differentiate among users of the
  59. same mailbox and post-delivery dispatching arranged on that basis.
  60.     But, yes, one could eliminate the personal-name part as not machine-
  61. addressable.  But there are still a number of variant forms.
  62.  
  63. >It would have the example of being
  64. >a little closer to something which one can test for equality.
  65.    Not much.   One of the intermittent interesting questions in email-
  66. land is "how do I look down a list of addresses and eliminate
  67. duplicates".  The general answer is "can't".  There are two problems,
  68. both of which related to the mailbox-abstraction issues discussed above.
  69. The first is that there are religious debates about whether
  70.    Joe <someuser@somehost>     and
  71.    Mary <someuser@somehost>    are the same
  72. The machine-processable mailbox strings are the same, but "Joe" and
  73. "Mary" tend to think they are different.
  74.  
  75. The second is that there is really nothing you can test for equality
  76. anyway.  I've just done a quick count and probably forgotten a few, but
  77. I've got at least eight addresses (different apparent mailboxes on
  78. different apparent hosts) that cause mail to appear in the vicinity of
  79. klensin@infoods.unu.edu, plus one that causes _most_ of the mail sent to
  80. it to appear here, but which keeps the rest.  It takes far more
  81. information than the mail system "owns" and will tell you to deduce the
  82. relationships.
  83.  
  84. >Would it be possible to remove all RFC822 quoting and apply
  85. >URL escaping as a reversable and well-defined transformation
  86. >which would presvent the horrible results of layered escaping?
  87.   At the risk of being cynical, it depends on the standards of quality
  88. to which you can hold implementors of URL systems and, to the degree to
  89. which humans have to see or type these things, those people.  If the
  90. quality is comparable to what we have experienced with email, it is
  91. hopeless--the quoting conventions in RFC822 are not implemented
  92. correctly by a painful number of systems (and they've had a decade to
  93. get it right).
  94.  
  95.   --john